Thread: [Weird Question] Where to break a line in C++ code?

Good places for newlines IMO:

• After conditional operators like || and &&. I don't recommend putting them after bitwise operators like (| and &) because it makes the code confusing.
• After assignment operators if and only if the RVALUE of the assignment does not fit on the line.
• In function calls and enums after comma separators. This greatly enhances readability when you have tons of parameters being passed to a function or a function takes tons of parameters, or an enum that has many enumerations.
• After each member variable in a class. Greatly enhances readability.
• If an inline class function will not fit on one line you should place the entire function below the prototype in the class. If the function is too long, it probably should not have the definition in the class.
• In template functions I always place a newline after template <class T>. The rest of the function is essentially the same as a normal function.
• In general it is not a good idea to have one line with 80 or more characters. These lines should be broken up.
• MSVC++ compilers allow you to place newlines when using literal strings. Example:
  
  Code:

  CString string("This is"
                         " one line of text");

  The compiler will concatenate these lines which is very handy. I have not been able to duplicate this behavior in the C# compiler. This feature is also fairly dependent on compiler implementations so I would not rely on it.
• Between sections of code that perform different operations inside the same function.
  
  Code:

  //Do Foo 
  int x = some_value;
  Foo(x);
  
  //Now do Bar
  int y = some_value;
  Bar(y);
  
  //Now do something else
  ...
  ...

  When your program gets larger this will help you differentiate different operations that are being performed in a function. Normally I try to create functions that do exactly one operation and do it very well. However, there are times when that one operation requires significant setup inside the function and it does not make sense to put the setup code elsewhere.

That is certainly not an exhaustive list but I hope it helps. It comes down to a style issue but I find that most programmers tend to adhere to a fairly common unwritten standard. There are exceptions of course.